Operating systems may fail (e.g., “crash”). When they crash, some operating systems may attempt to provide a text mode screen with information about the state of the computer and/or the operating system at the time of the crash. This text mode information may be useful in diagnosing the cause(s) of the crash. Unfortunately, the text mode screen may only display briefly until the operating system is automatically rebooted. For example, a watchdog timer may automatically reboot a system upon detecting a failure. Thus, techniques for capturing the text mode information before an automatic reboot occurred were developed. One technique includes continuously recording a character stream output by the operating system until a system reset is detected. Upon detecting the reset, recording is halted and a certain amount of the recorded character stream is stored to a known location, hopefully before the watchdog timer can reboot the system and cause the data to be lost. This technique requires continual textual recording, requires detecting a system reset and responding substantially instantaneously, requires dedicated resources (e.g., memory) and only works when the failure screen is provided in text mode. Furthermore, since the operating system may no longer have access to a file system and/or bulk storage devices like a disk drive, the failure data must be stored in memory that will retain its integrity after a system reboot.
Some operating systems (e.g., Windows 2003) may not provide text based crash-related information. Rather, these operating systems may be in a graphics mode at all times, including during crash processing. While continually recording a text stream may require a first acceptable level of system resources (e.g., memory) and may impose a first acceptable level of complexity and overhead on an operating system, continually recording a graphics stream may require a second unacceptable level of resources (e.g., memory) and may impose a second unacceptable level of complexity and overhead. For example, while storing an entire page of text mode data may require only 1 Kb of memory arranged in a circular queue where older characters can be replaced with newer characters, storing entire pages of graphics mode data may require substantially more memory, and may require more complicated data structures and processing. For example, up to 2.3 Megabits may be required to store an uncompressed 640×480 image.
Still other operating systems and/or utilities may attempt to provide a view of the computer screen as it looked at the moment the operating system crashed. These utilities are commonly referred to as screen capture programs. While these types of programs may provide a view of the screen when the system crashed, they may not provide crash-related information like that provided in the earlier text-based systems. Furthermore, while these programs may provide information about what was on the screen, they may not guarantee capturing a post-failure screen if one is available. Additionally, these types of applications may need to be installed on a server rather than residing in an off-server management processor. Therefore, the video capture may come from the additional installed software and create additional overhead on the server.